Computational and memory demands on computing systems continue to increase exponentially as technology develops newer and ever more powerful applications. One such area that has seen recent growth relates to requirements that database processing technologies that deal with dimensional aspects such as row and column processing are now being coupled with other models such as traditional object models having a class/inheritance structure. Thus, many systems often have a need to support both relational database models and object based models where there also needs to be methods in place to bridge the gap between these models. Demands to support such systems are often placed on available operating systems where a plurality of applications interact with the operating system but employ the system to interact with other applications. Some discussion on these two differing types of models is now provided before a discussion on memory constraints imposed by some applications employing such models.
Object-oriented programming (OOP) is a programming language model organized around “objects” rather than “actions” and data rather than logic. Historically, a program has been viewed as a logical procedure that takes input data, processes it, and produces output data. The programming challenge was seen as how to write the logic, not how to define the data. Object-oriented programming takes the view that what one really is interested in are the objects to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the display objects on a computer desktop (such as buttons and scroll bars).
One aspect in OOP is to identify the objects to manipulate and how they relate to each other, an exercise often known as data modeling. When an object has been identified, it can be generalized as a class of objects. Then, define the type of data it contains and any logic sequences that can manipulate it. Each distinct logic sequence is known as a method. A real instance of a class is called an “object” or, in some environments, an “instance of a class.” The object or class instance is what executes on the computer. The object's methods provide computer instructions and the class object characteristics provide relevant data. In contrast to object models, relational database models are now described.
Common relational database models are often supported by some type of query language for accessing and managing large amounts of data. Structured Query Language (SQL) is a prevalent database processing language and may be the most popular computer language used to create, modify, retrieve and manipulate data from relational database management systems. The language has evolved beyond its original purpose to support object-relational database management systems. In general, SQL was designed for a specific, limited purpose—querying data contained in a relational database. As such, it is a set-based, declarative computer language rather than an imperative language such as C or BASIC which, being general-purpose, were designed to solve a broader set of problems. Language extensions such as PL/SQL bridge this gap to some extent by adding procedural elements, such as flow-of-control constructs. Another approach is to allow programming language code to be embedded in and interact with the database. For example, Oracle and others include Java in the database, and SQL Server 2005 allows languages to be hosted within the database server process, while PostgreSQL allows functions to be written in a wide variety of languages, including Perl, Tcl, and C.
One area where object models and relational models cooperate is in the context of a reporting system or service. Prior art FIG. 8 shows an example prior art reporting system 800 adapted for an SQL/object model system. The system 800 includes a Rendering Object Model (ROM) 810 that receives data from a report snapshot 820 and outputs to a rendering extension component 830. The rendering extension component 830 receives parameters and other settings at 840 and produces a rendered output in a desired format at 850 (e.g., HTML, PDF).
In general, SQL Reporting Services depicted by the system 800 support a report processing and rendering engine that retrieves data and processes the entire report snapshot 820 as a whole. Thereby, the system 800 pre-generates all report item instances (such as textbox properties and values) in an output format independent intermediate format, and stores this information in chunks (i.e., streams of data). The chunks are de-serialized later during report rendering into the Rendering Object Model 810.
The ROM 810 is a representation of a report in an output-format independent object model representation. In the system 800, the ROM 810 is an instance object model allowing random access to all instances within a dynamic group collection. For example, a report matrix with 1000 row group instances and 1000 column group instances results in an overall matrix size of 1,000,000 cell instances. While all cells are directly accessible through the ROM, only a few may actually be needed to render a specific page at 850. The random-access flexibility of the ROM 810 comes with a considerable memory and performance cost. Despite very advanced caching strategies in the ROM 810, the overall object model still consumes a significant amount of memory and provides a lot of flexibility to rendering extensions 830 that is often not needed for efficient report pagination and layout rendering.